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A. DESCRIPTIVE TITLE OF PROPOSED INVENTION: 

A media gateway appliance for the delivery of Internet audio streaming services to cellular phones 

B. BACKGROUND: (1. The proposed invention relates to the field of...? 2. What problem does the 
proposed invention solve or what purpose does it serve? 3. What similar things are already known 
or available, ; e.g., closest known solution? 4. What are the disadvantages of these existing solutions?) 

Audio streaming is a popular application on the Internet today. As cellular wireless networks catch up with the frenzy 
of the Internet, we believe that there will be a big demand for similar services over cellular phones. However, cellular 
systems today cannot offer such Internet-style packet-based audio streaming. This is due to limitations in the cell 
phones and the cellular infrastructure, such as the lack of streaming protocols and decoders on the cell phones and the 
limited bandwidth in the infrastructure. 

We have designed a media gateway appliance, called Jharna, which enables delivery of audio streaming services to 
cell phones without requiring any changes to the cell phone or the infrastructure. 

C. DESCRIPTION OF INVENTION: (1. What is the proposed invention? 2. How does it 
operate? 3. What features are believed to be new?) 

i) Summary 

Jharna is a media gateway appliance that enables delivery of Internet audio streaming services to cellular phones. The 
Jharna system is architected as a "drop-in box" that delivers streaming audio to existing cellular phones without 
requiring any modifications to either the phones or the infrastructure. The key idea in Jharna is to provide audio 
streaming through a combination of call control, session management, and media translation mechanisms, while 
leveraging audio delivery and mobility functions in the existing cellular infrastructure. Jharna is also designed to work 
with emerging infrastructure technologies such as WAP. 

ii) Detailed Description (keyed to drawings/sketches/photographs, etc., sufficient to enable one 
skilled in the invention's field of technology to understand construction and operation of the invention. 

The operation of the cellular audio streaming service and the technology components in Jharna are briefly 
summarized next. The details are given in the accompanying document. 
Service Architecture 

Jharna provides a way to deliver audio streaming service to cellular users. The following steps describe how 
the service works. 
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Service Architecture 

Jharna provides a way to deliver audio streaming service to cellular users. The following steps describe how 
the service works. 

1. The cellular user dials a number (for e.g. 1-800-JHARNA1) to reach Jharna. 

2. The mobile switching center (MSC) in the cellular network forwards this call request to Jharna 

3. Jharna responds to the call (e.g. off-hook signaling) 

4. A service presentation layer provides the caller with options to determine what content to play (e.g. which 
music, which site. An example request is 'the top 2 jazz singles from mp3.com'). Jharna provides content in 
two forms: live content and on-demand content. 

5. Jharna establishes a session with the content server over the Internet, based on the request. 

6. Once a session is established, Jharna receives the streaming packets from the content server. 

7. Jharna translates the streaming audio to PCM format and sends it over to the MSC 

8. The MSC sends the data over to the cell phone over the speech channel 



Jharna Technology 

Jharna is a box that could be hosted in the service provider's premises. Jharna consists of the following 
components: 

1. Service Control unit 

This unit interfaces with the call from the cellular network side, presents service options to the cellular client, 
and processes playback control signals from the client. 

2. Session Control unit 

This unit interfaces with the content server on the Internet to set up a session corresponding to the streaming 
request. It is also responsible for converting the playback options to session control signals. 

3. Media translation unit 

This unit converts the incoming audio stream to a format suitable for transmission over the speech channel in 
the cellular network. 

Other technology components in Jharna include the Audio Session Gateway Protocol (ASGP) and the Cell 
Casting Protocol. 

Audio Session Gateway Protocol (AGSP). We have defined the audio session gateway protocol that enables 
the cellular phone to be used as a virtual streaming player. The protocol establishes a means to convert 
playback controls from the cell phone to a format suitable to the streaming session. 

Cell Castine Protocol : We have defined a cell casting protocol for efficient streaming of broadcast channels. 
The protocol defines a mechanism for multicasting channels that are shared between multiple clients to reduce 
bandwidth usage as well as processing load. 

D. ADVANTAGES/COMPARISON: (What are the main selling points of your invention, i.e., what 

will your invention do that could not be done before?) 

1 Jharna is the first media gateway appliance that allows audio streaming over the cellular network, the architecture 
of Jharna enables it to deliver a service that was previously considered impossible on existing phones and 

infrastructure . ,., Anm . 

2. Jharna works with all air interfaces (CDMA, TDMA, GSM, etc.) and all cell phones (with and without WAP/IP 

support) 

3. Jharna does not require content to be re-authored; it can deliver existing audio content. 

E. USE: (1. What are the probable uses? 2. Is it scheduled for use in a Lucent product or service? If 
so, which one and when? 3. Is this idea likely to be adopted by others outside of Lucent? 

4. Is it likely to become a standard? 5. Do you see any broader applicability for the idea?) 



Jharna enables a service that would be deployed by cellular service providers (e.g .Bell Atlantic). 
Value proposition for Service providers : 

1 . Cellular service providers can offer service differentiation by providing next-generation multimedia services like 
audio streaming through Jharna, while still leveraging their existing infrastructure. This is especially important to 
retain and acquire new customers, especially in a market where churn is a big problem. 

2. By exciting customers with next-generation services today, service providers can establish a demand for higher-rate 
3G services. 

3. Providing a new service such as audio streaming has the potential to increase the air time usage, which leads to 
increased revenues. 

Value Proposition to equipment vendors (Lucent) 

Equipment vendors such as Lucent stand to benefit by packaging Jharna within the cellular infrastructure components 
sold to service providers. Since Jharna is the first such streaming gateway, it offers Lucent a way to differentiate itself 
from other vendors. 

F. FOREIGN INTEREST: (In which foreign countries, if any, should we obtain a patent and why? ,. 
e.g., big market there, major competitors are based there, etc.) 

Need to discuss this. 

G. PUBLICATION OF PROPOSED INVENTION: (List publications, if any, which have 
described the proposed invention. Include dates.) 



None yet. 
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Summary 

We have designed Jharna, a media gateway appliance that enables delivery of Internet audio 
streaming to cellular phones. 

The Jharna system is architected as a "drop-in box" that delivers streaming audio to existing 
cellular phones without requiring any modifications to either the phones or the infrastructure. 
The key idea in Jharna is to provide audio streaming through a combination of call control, session 
management, and media translation mechanisms implemented on the Jharna appliance, while , 
leveraging audio delivery and mobility functions in the existing cellular infrastructure. Jharna is 
designed to also work with emerging technologies such as WAP. 

1. Background: The case for cellular audio streaming 

Personalized audio streaming 1 is an extremely popular application on the Internet today, as 
demonstrated by the immense popularity of music in the MP3 [1], Real Audio [2], and Microsoft 
Media [3] formats. With the increasing proliferation of cellular users and the trend towards 
ubiquitous services, we believe there will be a big demand for similar applications over cellular 
phones. A recent study by Arbitron [4] found that over 75% of polled web users expressed interest 
in portable streaming services, saying they would increase their tuning into streaming programs if 
these services were made available on "portable" devices. 

Consequently, there is a definite market opportunity in delivering streaming audio services over 
cellular networks. 

2. Why is cellular audio streaming hard? 

Audio streaming on the Internet uses a packet-based approach, where the audio source is broken 
down into packets, each packet is encoded, and sent to the client on the receiving-end in a certain 
sequence. The client receives the packets, decodes them, and plays them out on the receiving 
terminal. 

Cellular systems today cannot offer such Internet-style packet-based audio streaming due to 
limitations on both the terminal and the infrastructure end. 

(a) Phones can not support streaming since they do not have decoders (e.g. mp3 decoder) or 
streaming controls (skip, pause, etc.). So even if packetized encoded streaming data were 
sent to the phone, the phone would not be able to decode it and play it out. 

(b) The data rates in the cellular networks today are quite limited and are insufficient to transport 
encoded streaming packets 3 . Thus, the infrastructure is not capable of delivering these 
packetized streams to the phone. 

Thus it is not possible to support packet-based audio streaming on existing cellular phones using 
the existing infrastructure. 



1 Streaming is a technique of breaking up a media file (e.g. audio) into packets and sending those to the user in a 
sequence. The receiver is able to play the data as soon as it arrives, instead of waiting for the entire file to download 

2 IDC estimates 450 million cellular customers worldwide in year 2000 (90 million in the US). [IDC 1999] 

3 A typical mp3 encoded stream sent over the Internet requires 64kbps bandwidth. 
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3. Jharna: Cellular Audio Streaming Today 

The Jharna architecture overcomes the limitations of end-to-end packet-based audio streaming 
and is designed to provide streaming audio services over existing cellular networks using existing 
phones. 




Server 



Figure 1: Cellular Audio Streaming with Jharna 

As shown in Figure 1, Jharna is a gateway between the cellular network and the Internet. To use 
a Jharna-based service, the cellular customer makes a call to Jharna using her cell phone. Jharna 
is responsible for (a) establishing a session on the Internet in response to the call request, (b) 
retrieving streaming content from the server, (c) decoding the stream, and (d) translating it to a 64 
kbps PCM stream. This transcoded stream is then delivered to the cell phone over a standard 
speech channel using the underlying services in the cellular network. 

Thus the key ideas embodied in the Jharna architecture are: 

(a) Jharna is a gateway between the IP and the cellular domains that enables Internet services to 
cellular phones. In other words, Jharna is a "packet-data to circuit-voice" gateway. 

(b) Jharna leverages the "speech" channel in the cellular networks to deliver streaming audio from 
the Mobile Switching Center (MSC) to the cell phone 

(c) Jharna leverages the mobility support offered by the cellular bearers 

This architecture overcomes the limitations mentioned in Section 2. First, the need for streaming 
players and decoders on the cell phone is eliminated by performing the streaming session control 
and decoding on the Jharna appliance. The content can thus be played out on existing cell phones 
that do not have decoders and streaming players. Second, the content is played out over the 
speech channel 4 . Hence, there is no need for high bandwidth connections in the cellular network. 
Since the cellular network delivers the audio content, mobility and delivery issues are automatically 
taken care of. There are additional advantages: Since the output from Jharna is 64kbps PCM, it 
can be connected directly to the Mobile Switching Center (MSC) (either by co-locating it in the 
premises of the cellular service provider, or through a direct digital connection into the MSC). This 
placement makes Jharna easy to deploy since no changes are required in the cellular service 
provider's infrastructure. A further advantage of this architecture is that the delivery of streaming 
audio is agnostic to air interfaces - since all cellular bearers use 64kbps PCM for speech delivery. 
This enables Jharna to work seamlessly with all air interfaces (GSM, TDMA, CDMA,). 

Thus service providers can use Jharna to deploy audio streaming, a next-generation service, while 
still leveraging their infrastructure. This new service gives them a way to offer service 
differentiation. Also, there is a potential to increase on-time through this service, leading to 
increased revenues. Finally, by developing a mind-share for next-generation applications now, 
cellular service providers can establish demand for 3G services. 



4 We have performed extensive measurements that indicate that the quality of the received content is still acceptable at this 
lowered rate. 
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The next few sections discuss architecture in some detail. In Section 3.1 we describe a high-level 
overview of the service architecture. In Section 3.2 we describe the main components of the 
Jharna appliance. Details of the architecture are described in Section 3.3. 

3.1 . Jharna Service Architecture 

Figure 2 shows the Jharna service architecture. 

1 . The cellular user dials a number (for e.g. 1-800-JHARNA1) to reach Jharna. 

2. The MSC forwards this call request to Jharna 

3. Jharna responds to the call (e.g. off-hook signaling) 

4. A service presentation layer provides the caller with options to determine what content to play 
(e.g. which music, which site. An example request is 'the top 2 jazz singles from mp3.com 1 ). 
Specifically, Jharna provides three types of service, (a) Live content: e.g. Internet radio (b) On- 
demand content: e.g. play back a certain song from mp3.com (c) Profile playback: Users 
maintain a profile on a server. This profile is used to play back content to the cellular client. 

5. Jharna establishes a session with the content server over the Internet, based on the request. 

6. Once a session is established, Jharna receives the streaming packets from the content server. 

7. Jharna translates the streaming audio to PCM format and sends it to the MSC 

8. The MSC delivers the audio content to the cell phone over the speech channel 
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Server 
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Figure 2. Jharna System Architecture 



Several features enhancements over this basic service architecture are possible. For instance, in 
step 1, instead of calling a specific number, a service provider can offer a customized service. In 
this scenario, the user may call a service such as U *MP3". The service presentation in step 4 can 
present information to the user in several formats, including standard IVR (interactive voice 
response), a WAP interface, or a VoiceXML interface [10]. 

3.2. Jharna Technology 

Figure 3 shows the main components of Jharna. 

1 . Service Control unit 

This unit is responsible for interfacing with the call from the cellular network side. It presents 
service control options to the cellular client, processes service requests, and processes 
playback commands. 

2. Session Control unit 

This unit interfaces with the Internet. It establishes and controls a session with the content 
server. It also implements the audio session gateway protocol (ASGP). The ASGP converts a 
cell phone into a virtual personalized player by translating the playback control requests from 
the client to session commands sent to the server. 

3. Media translation unit 

This unit receives encoded streaming audio content (e.g. MP3) over the Internet, decodes it, 
and converts it to a format that can be delivered to the cell phone (e.g. PCM). 



3 




Figure 3. Jharna Components 



3.3. Jharna Technology details 
Service Architecture 

Figure 4 describes the service architecture as presented to the user. The user calls a number. If 
the user has already created a service profile, data from that is used to control the session. If there 
is no profile, the user is presented with two options: live or on demand. In the case of live content, 
the user is played back different live channels (similar to the "scan* mode on radio). The user 
selects the particular channel to be played out. In the case of on-demand content, the user selects 
the genre and the play-list for that genre is played out to the user. In both these cases, the user 
can control the playback (walkman-style controls) by pressing appropriate buttons on the phone. 
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[playback selected genre play-list] 4"" 



v \ Walkman 
-J controls 



User input 
< system prompt> 
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Figure 4: Service architecture (user interface) 



System Architecture 

Figure 5 describes the details of the different components in the Jharna appliance. The telephony 
interface is on the left side, while the Internet interface is on the right side. The Call Interface 
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Process is responsible for receiving and terminating calls and assigning each call to a specific 
process. The shaded box contains the processes that are active for each call. The Service 
Control Module presents the service options to the caller, processes service requests, and also 
processes playback control messages (e.g. forward, pause, etc.) through DTMF processing. The 
Session Control Module sets up and maintains a session with the content server. It also 
implements the Audio Session Gateway Protocol (ASGP) that allows the cell phone to remotely 
control the playback options. The Media Translation Module decodes the streaming audio 
content and converts it to the PCM format. The Line Driver Module sends out the audio content 
over to the line. This module receives input from different processes: playback options from the 
service control module, on-demand data from the media translation module, and live data from the 
session control module. Details on the live content are described next. 

In the context of figure 4 we described that the content provided could be either live or on-demand. 
In the case of live content, we have designed a mechanism that allows multicasting of the data to 
different users. We term this "cell casting". Cell Casting reduces the bandwidth and processing 
overhead when multiple clients want to listen to the same content. Figure 5 shows the 
components for Cell Casting. The Cell Casting Module sets up sessions for all broadcast 
channels, as shows in the figure. This module maintains a list of all channels, the address where 
the content is found, and a set of groups of users for each channel. The Scan Channel Module is 
used to provide the scan content described in Figure 4. This module multiplexes data from all the 
channels to provide a single stream. The service control module plays out this scan stream to 
allow the user to select a channel in the live mode. 
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Figure 5: System Functional Architecture 



Service Control Module 

Figure 6 shows the detailed state diagram for the Service Control Module. This module is created 
when the call is received. This first spawns a session control module for this call. Next, it checks If 
a profile exists for this user. If it does, it goes into state 3. If there is no profile, it presents options 
to the user to select on-demand or live mode. The selection is detected through DTMF processing. 
In case of state 1 (live), the scan channels are played back to the user and the selection is 
conveyed to the session control module. The process continues to detect DTMF tones for other 
play-back requests from the user. In state 2 (on-demand), the genres are played back to the user. 
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The selection info is conveyed to the session control module. As in state 1, it continues to monitor 
play-back requests from the user. In state 3 (profile), the user profile is looked up to select the 
session. 
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Figure 6: Service Control Module 



Session Control Module 

The Session Control Module is described through Figure 7. 
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Figure 7: Session Control Module 
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This module comprises two states, depending on whether the user has picked the on-demand 
mode or the live mode. (Note that the profile selection maps into one of these modes, depending 
on the user's selection.) In the case of the on-demand mode, the appropriate http/rtsp session is 
set up with the server. The media translation module is spawned for this call so that it receives the 
streams for this session. The module then continues to detect the control playback commands 
from the service control module. The ASGP is used to translate the playback commands into 
session requests to the server. 

In the case of the live mode, the channel selection is used to query the Cell Casting module for the 
address of this channel. The line driver unit is instructed to. forward data from this channel. The 
AGSP manages the session playback control as in state 1. An additional option in state 2 is a 
"record" option, which allows the user to record a segment of the channel into her personal profile. 



Audio Session Gateway Protocol 

The Audio Session Gateway protocol is summarized in Figure 8. The figure outlines the typical 
commands required and their mapping into session requests. The actual conversion signals 
depend on the player used. 
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Figure 8: Audio Session Gateway Protocol (ASGP) 



Cell Casting Module 

The Cell Casting Module is shown in Figure 9. This module is started when the system comes up. 
For every channel in the list of live sessions, it spawns a session control module and a media 
translation module. The Cell Casting controller maintains a list of channel-to-address mappings for 
each channel. The session control module uses this information to determine the address for a 
specific channel. An alternative implementation is to have the session control module make 
requests to join a specific group. The Cell Casting controller maintains a list of active groups and 
sends copies of the data to appropriate groups. The Scan Channel controller generates a "scan" 
stream that is played out to the user in the live mode. This module multiplexes content from all the 
live streams to a single stream. 
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Figure 11: Cell Casting Module 

Media Translation Module 

The Media Translation Module shown in Figure 10 receives streaming content from the server. It 
decodes the content to generate a decoded bit stream. This bit stream is typically at a sampling 
rate of 44.1 or 48 kHz. Since the output is required at 8Khz, the samples are first low-pass filtered 
to avoid aliasing. Next, they are passed through the rate conversion filter. This filter is designed as 
a multi-stage filter to reduce the filter length. Finally, it is passed through a mu-law converter. 
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Figure 8: Media Translation Unit 



Line Driver Module 

The Line Driver Module is shown in Figure 1 1 . This module multiplexes input streams to the output 
PCM channel. The implementation of this module depends on the API's provided by the underlying 
hardware platform. 
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Figure 11: Line Driver Module 



WAP-based operation 

As mentioned earlier, the Jharna system is architected to work with emerging technologies such 
as WAP. Figure 12 shows the service architecture using a WAP phone. 




Figure 12. Jharna Service Architecture using WAP 

1 . The user uses the WAP browser on the terminal to request an audio streaming application 

2. The WAP gateway translates the WSP request from the WAP client to an HTTP request to 
Jhama. The WAP server and Jharna could be on the same physical machine or could be 
connected through an IP link. 

3. Jharna uses information from the WAP server to set up a session with the content server. 

4. The WAP server instructs the WAP client on the phone to get into a "call accept" mode 

5. Jharna initiates a call with the WAP client on the phone through the MSC 

6. Jhama receives streaming audio content from the content server 

7. Jharna translates the media to a format suitable to send to the MSC 

8. The MSC sends the audio stream to the cell phone 



Figure 13 shows the system architecture with WAP. In the Jhama implementation, the service 
control module is now implemented as a WAP application on a WAP server. The rest of the 
system remains the same. In this mode, the user requests service by going to a URL. The WAP 
application presents the user with service options, similar to those offered by the Service control 
module. The user responses are conveyed to the Session control module as before. Playback 
controls in the WAP applications are also passed on to the Service control module to be 
processed through the ASGP. One additional function of the new Service Control Module is that 
on receiving service request, it has to put the WAP phone into a receiving mode. The service 
control module then establishes a connection with the phone. The streaming data is sent to the 
user over this channel. Thus, other than the service control module, the rest of the architecture 
remains the same for WAP-based phones. 
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Figure 12: WAP-based service control module 
3.4. Jharna Implementation 

A Jharna prototype based on the architecture described above is currently being implemented. 
The prototype is running on a standard PC running Windows NT. The PC has line cards (Dialogic 
D240/PC1-T1 or Natural Microsystems AG4000) to terminate the phone call. On the Internet side, 
Jharna is connected through Ethernet or other high-speed links to the Internet. This is summarized 
in Figure 14 and Figure 15. Figure 15 shows the line card (AG4000) and its associated kernel 
(CTAccess kernel). The call interface process and the line drivers are implemented using these 
API's. 
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Figure 4. Jharna Prototype (System Architecture) 
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Figure 15. Jharna Prototype Details 
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3.5. Jharna: Enhancements 

Caching can be used to enhance the performance of streamed audio. A caching scheme can be 
incorporated into Jharna, allowing frequently accessed content to be delivered more efficiently to 
end-users. The media translation module will also likely be implemented in hardware to improve 
scalability. 

4. Technology positioning 

Jharna is the first media gateway to deliver streaming audio content to cellular phones. The 
following table compares Jharna to other technologies in related areas. None of them are in the 
same service space as Jharna is. Also, Jharna is least disruptive in deployment and demands no 
changes from the terminal or the infrastructure. 

a. WAP 

WAP is a technology for delivering HTML content to cell phones through transcoding or 
content re-authoring. WAP focuses on translating web content (text and graphics) to a format 
that is suitable for cellular terminals. Deploying WAP-based services requires WAP-compliant 
phones and gateway. WAP alone can not deliver streaming audio packets. WAP can be used 
to provide the service interface to Jharna as shown in this document. 

b. VoiceXML 

This is a standard for providing voice-enabled access to web content. Content needs to be re- 
authored in the VXML format before it can be delivered on the audio channel - it can not 
support streaming audio. Typical applications are for interactive voice response, e-commerce, 
and web browsing, which are different from real-time audio streaming. 

c. IP support on cellular networks 

There is a lot of activity in delivering data over cellular networks. Since IP is the dominant data 
networking protocol, most of the work in this area focuses on delivering IP over cellular 
networks. Managing mobility is one of they issues in supporting IP over cellular networks and 
approaches such as Mobile IP [7] HAWAII [8] and Cellular IP [9] focus on solving the mobility 
problem at the IP layer. These approaches focus on applications such as data on the end 
terminal and voice over IP. They do not address audio streaming. Further, these approaches 
require the terminal to supporting an IP stack and the infrastructure needs to be modified to 
support mobility. Our approach, on the other hand, leverages the mobility support provided by 
the underlying bearer network. Also, the service focus is entirely different. 
There have been other activities related using the cell phone to download music. In this case, the 
cell phone is basically used as a modem. This is a different application from streaming. Ericsson 
recently announced a FM radio that can be attached to the cell phone. Again, this is not streaming 
or Internet audio and hence addresses a different problem. 

In summary, Jharna offers a unique service offering and its architecture makes it very easy to 
deploy. 





Service 


Terminal 


Infrastructure 


Content 






Changes 


Changes 


Changes 






Required? 


Required? 


Required? 


Jharna 


Audio Streaming 


NO 


NO 


NO 


WAP 


HTTP translation 


YES 


YES 


Maybe (WML) 




and web delivery 




(gateways) 


YES (VXML) 


VoiceXML 


Voice-enabled 


NO 


NO 




Web access 






NO 


Cellular IP 


Data, VoIP to end- 


YES 


YES 




points 




(BS, MSG, gateway) 





Table 1 : Comparison of Jharna with other approaches 



11 



5. Summary 

In summary, Jharna enables next-generation multimedia applications over current-generation 
cellular networks. The Jhama gateway is used to seamlessly deliver streaming audio to 
cellular phones. 
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